One way to ensure the atomicity of certain transactions in a database is to delay writing the results of any one operation to a database until all of the operations in the “atomic” transaction have been deemed successful. Then a “commit” operation is performed, and all of the operations in the “atomic” transaction are written to persistent storage. This practice is often used in mission-critical and/or commercially important situations in combination with performance of logging—where all or most all operations performed on a database are logged to a “redo log” for later replay or redo. In some cases transaction logging is used in combination with other high-integrity and/or high-availability techniques. One such combination involves write-ahead logging (WAL). Write-ahead logging, when used in combination with synchronized commit operations, can guarantee that no changes are committed to disk until such time as the corresponding redo log records are confirmed to have been written. Used in this manner, write-ahead logging ensures the atomicity and durability components of the “atomic”, “consistent”, “isolated” and “durable” (ACID) properties favored in database systems. However, write-ahead logging introduces latency during transaction commit because a committing process must wait for (1) the redo log write to complete, and must further wait for (2) receipt of a success indication from the redo log writer.
In database management systems, this redo log write synchronization can be accomplished by using a “post-wait” technique or by using a “poll-wait” technique. A post-wait technique uses the interrupt mechanism of the underlying operating system, while a poll-wait technique uses a memory access and compare. In most situations the cost for a process to perform a single “post-sleep-wait-resume-continue” series of operations is more expensive than a single “poll-continue” operation. Comparing the two, post-wait and poll-wait each offer differing advantages and disadvantages under different circumstances depending on the system, the system configuration, and the aggregate processing of work on the system. Generally, post-wait offers lower latency when only a single process or few processes are trying to commit a transaction. And, generally, poll-wait techniques scale better as the number of committing processes increases.
Legacy techniques are deficient in that a selected synchronization technique might have been appropriately selected at the time of selection and deployment, however system configurations and workloads change over time, in fact, system configurations might change quite substantially, even in a relatively short period of time.
Moreover, none of the aforementioned technologies have the capabilities to perform the herein-disclosed techniques for adaptive high-performance database redo log synchronization. Therefore, there is a need for an improved approach.